Portico supports CoF processing for the following financial transactions:

• CreditAccountVerify
• CreditAuth
• CreditIncrementalAuth
• CreditReturn
• CreditSale
• RecurringBilling
• RecurringBillingAuth

The CardOnFileData block in the transaction request is used to communicate the required CoF data and is composed of two fields:

• CardOnFile
  • This indicates who initiated the CoF request.
  • This must be included in all CoF transactions.
  • Valid values are:
  • C = customer initiated
  • M = merchant initiated
• CardBrandTxnId
  • This must be included in all subsequent CoF transaction requests.
  • This is the CardBrandTxnId value from the authorization response message of either the initial CoF transaction or the most recent transaction using the stored credential.

The CardBrandTxnId in the transaction response is a Brand transaction identifier that is passed back to the POS if received. When placing a credential on file the POS should save this value for use with subsequent CoF transactions. If a transaction indicating that the credential is being placed on file fails then the credential cannot be considered a stored credential and the merchant must not use the credential for any subsequent transactions.

Each transaction request that either will store or is using previously stored credentials should now include the CardOnFileData block, as shown below:

• Initial CoF—Transaction request that puts the credential on file in the system.
  • Include the CardOnFile indicator in the request.
  • Store the CardBrandTxnId from the authorization response with the stored credentials.
• Subsequent CoF—Transaction request that uses previously stored credentials.
  • Include the CardOnFile indicator in the request.
  • Include the CardBrandTxnId of the initial or most recently approved transaction using the stored credentials.
• Existing CoF—For merchants that already have credentials on file.
  • Include the CardOnFile indicator in the request.
  • Include the CardBrandTxnId of the most recently approved transaction using the stored credentials.

Merchant Initiated Transactions

Additional information is provided below regarding specific merchant initiated transactions.

The following types of transactions should not be used to place a credential on file but are considered subsequent CoF transactions if a stored credential is being used. The CardOnFileData block should be included in these requests.

• Incremental Authorizations
• Lodging Delayed charges
  • The Card Brands require the CardBrandTxnId of the original authorization regardless of whether the credential was placed on file or not.
• Lodging No Show charges
  • The Card Brands require the CardBrandTxnId of the original authorization regardless of whether the credential was placed on file or not.
• Repeat Sales

Recurring billing requests are usually subsequent CoF transactions. Portico does allow these transactions to be formatted as initial CoF in order to support that scenario. The CardOnFileData block should be included in the request message to Portico for:

• Recurring Payments (recurring payments where the One Time Indicator = N)
• Unscheduled CoF (e.g., tolltag top-up)

CreditReversal/CreditVoid

Portico is handling the necessary CoF requirements on behalf of the merchant or integrator for the CreditReversal and CreditVoid services.